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REMARKS 

Reconsideration of the rejections set forth in the Office Action is respectfully requested. 
By this amendment, claims 11-14 and 23 have been canceled without prejudice or disclaimer, 
and claims 1-2, 5, 9-1 0, 15, and 17 have been amended. Currently, claims 1-10 and 15-22 are 
pending in this application. 

Objection to the specification 

The Examiner objected to the specification because Paragraph 51 referenced LRS as 
being shown in Fig. 6. Applicants have amended Par, 51 as shown below, with strikeout being 
used to show deleted text and underlining being used to show inserted text. The Examiner is 
requested to approve this amendment to the specification when acting on this Amendment. 

[005 1] Local MAC addresses maybe assigned manuall y, for example as was don e in connection 
with Fig. 4 and as dogcribod above . However, with a large network with hundreds of switches 
and tens or hundreds of thousands of end devices., this may not be practical. Figa. 5 and 6 
rolleetive^ a m a n ner in wl neh Thus, local MAC addresses may be 

assigned on a local domain automatically, for example by a Location Resolution Server (LRS) 
1 8 (see Fig. 4 Figs. 4 and 6. ). While the functions of the LRS 1 S will be described in. connection 
with assigning LMAs on the network, the functionality of Lhe LRS is not limited to this aspect of 
interaction on the network, as the LRS may also be used to perform other services, such as 
resol ving addresses on the network. 

Rejection under 35 USC 101 

Claims 10-14 were rejected under 35 USC 101 as being directed to non-statutory subject 
matter. Specifically, the Examiner has taken the position that a protocol data unit is a data 
structure, which the Examiner contends is an abstract idea and a mere arrangement of data. As 
support for this position the Examiner has cited MPEP 21,06,01, Applicants have amended claim 
10 to recite a "protocol data unit data structure stored in a tangible computer readable medium . 
the protocol data unit data structure comprising. . 

As set forth in MPEP 2106,01, when functional descriptive material such as a data 
structure is recorded on some computer-readable medium, it becomes structurally and 
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functionally interrelated to the medium and will be statutory in most cases since use of 
technology permits the function of the descriptive material to be realized. In view of the 
amendments to the claims, applicants respectfully request that the rejection under 35 USC 101 be 
withdrawn. 

Rejection under 35 USC 102 and 35 USC 103 

All pending claims in this application were rejected under 35 USC 102, or under 35 USC 
103. Applicants have amended the claims to overcome these rejections. Accordingly, in view of 
the claim amendments, these rejections are believed to be moot, .However, to expedite 
prosecution, applicants will provide an explanation as to how the amended claims overcome 
several of the pieces of cited art more heavi ly relied on by the Examiner in the Office Action. 

This application relates to a way to allow a switch to directly identify the output port for a 
given frame without performing a table access operation, (Specification at Paragraph 18). 
Specifically, applicants discovered that it would be advantageous to provide a frame with frame 
contained destination information that would allow one or more switches on the network to 
receive the frame, look at the destination information, and output the frame on a correct port to 
that destination without requiring the switch to perform a table lookup. 

Claims 1, 3, 5-6, 10, and 12 as originally presented were rejected under 35 USC 102 as 
anticipated by Schaub (U.S. Patent No, 7,190,695). Schaub does not teach or suggest a switch 
that can receive the frame, look at the destination information, and output the frame on a coiTect 
port to that destination without requiring the switch to perform a table lookup. 

Fig. 3 of Schaub shows the internal structure of a switch/router 300 (Schaub at Col. 5, 
lines 4-5). As shown in Fig. 3, the switch/router has a 10GB Ethernet physical layer unit (PHY) 
310 that will allow it to connect to a 10GB Ethernet data link. To avoid using specialized 10 Gb$ 
layer 2 and 3 processors (Schaub at Col. 6, lines 8-10), Schaub teaches that it would be 
preferable to use 10 x 1 Gbs processors. (Col. 5, lines 63-Col. 6, line 12). This allows readily 
available 1 Gbs subsystems to be used to process the incoming packets. 

Schaub realized that splitting the incoming lOGbs stream could be analogized to 
distributing packets between parallel links in a link aggregation, system. Specifically, at Col. 1, 
lines 62-63, Schaub teaches that link aggregation is commonly used to connect two network 
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nodes with multiple physical links. Schaub continues at Col. 2, lines 1-6, to explain that the link 
aggregation involves a distribution function that receives packets from a higher rate link and 
distributes the packets amongst the lower rate links. 

Schaub then borrows this distribution concept from link aggregation, and implements it 
in the switch/router 300 as packet distributor 312. (Schaub at Col. 5, lines 37-41). Specifically, 
the packet distributor receives the packets from the lOGbs link and distributes the packets to 
multiple internal 1 Gbs links 322. (Id. See also Schaub at coL 6, lines 13-17). The internal 
lGbs links extend from the lOGbs PHY to the MAC/packet processors. 

The particular way in which Schaub distributes the packets to the various MAC 
processors is not particularly important. Briefly, the packet distributer looks at various fields of 
the headers to determine the category type of the packet. Based on the category type of the 
packet a mapping function is selected, which is then used to cause .the packet to be output on one 
of the lines 322 to the MAC processors. (See Schaub at Coh 3, lines 51-62; and Col. 6, lines 13- 
22). 

The distributor 312 described above allows the packet to be received at the physical 
interface (.PHY 310) and output to one of the internal I Gbs links 322. The links 322 carry the 
packet to one of 10 sets of parallel processors. Specifically* each link 322 is connected to a 
MAC processor that reads the layer 2 header of the incoming packets and performs a layer 2 
lockup to determine how to forward the incoming packets to their next destination within the 
switch. (Schaub at Col. 5, lines 42-46), The packets are then conveyed to the packet processors 
316 which performs a next hop (layer 3) address lookup for the routed packets (when necessary). 
(Schaub at CoL 5, lines 52-57). 

Based on the layer 2 lookup performed by the MAC 314 or the layer 3 lookup performed 
by the packet processor 316, the packet will be input to the switch fabric 318 where the packet 
will be switched according to the result of the table lookup. (Schaub at Col. 5, lines 56-62). 

Thus, Schaub uses standard forwarding table lookup operations to determine an output 
port for a particular packet. The forwarding table lookups are performed by the MAC 314 or the 
packet processor 316, or both. The packet distributor is used to select which of the several 
parallel sets of processors should be used to perform the lookup for that particular packet, but the 
result of the distributor does not in any way affect the ultimate selection of the output port 320 
from the switch/router. 
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Manur teaches at col. 7, lines 6-9, that the processor 11 OA receives a packet and determines a 
destination address DA from the header of the received packet. Manur then states, that the 
destination address 11 2 is used as a basis to index into content addressable memory 120 to obtain 
the next hop egress port identification. (Col. 7, lines 1-18). Manur explains in some detail how 
the content addressable memory may be used to determine the next hop egress port by indexing 
into various tables. (See e.g. Manur at Col. 7, lines 19-28; Col. 7, lines 37-49; Col. 8, lines 18- 
28) 

In all of these instances, Manur refers to the process of "determining" the egress port and 
then describes that the process is accomplished by performing a lookup in one or more tables. 
Accordingly, the natural reading of step 238 would be that, if link aggregation was not required, 
the processor would use the destination address to ''determine" the egress port by using the 
destination address lo index into the CAM 120. Thus, applicants respectfully submit that the 
cited portions of Manur, when read in context, do not teach or suggest a method that will enable 
a frame to be forwarded to an. output port based on. frame contained destination information 
without performing a table lookup operation to determine the output port. 



Claims 10 and 15 

Independent claim 10 has been amended to recite that the protocol data unit lias a 
destination Media Access Control (MAC) address, the destination MAC address being a local 
MAC address having a plurality of fields, each of the fields including a number of bits smaller 
than a total number of bits of the destination MAC address, and each of the fields containing a 
code to be used by a switch on a network to identify an output port on the switch without 
performing a table lookup operation, wherein each of the fields is to be used by a different switch 
on the network. 

Independent claim 15 has been amended to recite a method of assigning a Media Access 
Control (MAC) address to an interface on a network, by assigning a first value to a first field of 
the MAC address, the first field containing a smaller number of bits than a total number of bits of 
the destination MAC address, said first value containing first output interface information usable 
by a first switch to identify a first output interface for transmission of frames containing the first 
value in the first field of said MAC address. 
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To distinguish what is being claimed in this application from the distribution function 
shown in Schaub, applicants have amended claim 1 to recite a method of switching frames that 
includes the steps of making a switching decisi on based on extracted frame contained destination 
information without performing a lookup in a forwarding table to determine an output port from, 
the first switch over which the frame should be forwarded onto the communication network; 
forwarding the frame within the switch to the output port over which the frame should be 
forwarded onto the communication network; and transmitting the frame from the determined 
output port onto the communication network. Claim 1 has further been amended to recite that 
the method enables a received frame to be transmitted from an input port to a determined output 
port and then onto the communication network based on the frame contained destination 
information without performing a table lookup operation to determine the output port. 

Schaub does not teach or suggest a method of this nature, Specifically, Schaub does no! 
teach switching frames within a switch based on frame contained destination information to an 
output port from which the frame will be transmitted onto a communication network without 
performing a table lookup operation. Accordingly, applicants respectfully submit that claim 1, as 
amended, is patentable over Schaub. 

Claim 2 was rejected under 35 USC 103 as unpatentable over Schaub in view of Manur 
(U.S. Patent No. 7,190,696). Specifically, the Examiner noted in connection with this rejection 
that Schaub docs not teach reading a portion of a header of the frame and causing the frame to be 
passed directly to the output port. However, the Examiner has taken the position that Manur 
teaches this feature, citing Fig. S, elements 230 and 238. 

Manur relates to a system that is able to distribute packets across equal cost paths to a 
common destination, or between links that have been designated as belonging to a link 
aggregation group (Manur at Col. 1, lines 39-46). Fig. 8, cited by the Examiner, is described as 
showing a method of distributing packet flows across links associated with a given link- 
aggregation. If link aggregation is not enabled (230, 232, 236) Fig. 8 states that the process will 
"determine a next-hop egress port ID based upon the destination address." The text at col. 10, 
lines 29-34 state that the next-hop egress port is determined "directly" via the destination 
address. As far as applicants can tell, step 238 is not discussed elsewhere in Manur. 

Applicants respectfully submit that these sections of Manur do not teach that the next hop 
egress port will be known from the destination address without a table lookup. Specifically, 
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These claims arc patentable over the cited art because the cited art does not appear to 
teach or suggest using portions of a MAC address to switch traffic wiuiin a switch. 

In connection with claim 15, the Examiner has taken the position that Pearce (U.S. Patent 
No. 6,556,574) teaches assigning values to fields of the MAC address, citing col. 20, lines 10-18 
of Pearce. The cited portion of Pearce relates to Fig. 10, which Pearce describes as an "ARP 
table" (Pearce at Col. 19, lines 65-67). As described by Pearce, the ARP table allows the route 
information to be given as part of the layer 2 MAC address, and also allows a binding between 
the layer 2 MAC address and layer 3 IP address to be provided. This cited portion does not teach 
or suggest the use of sub- fields within the MAC address. 

Conclusion 

In view of the amendments to the claims and the foregoing .remark?, it is respectfully 
submitted that the application is now in condition for allowance and an action to this effect is 
respectfully requested. If there are any questions or concerns regarding the amendments or these 
remarks, the Examiner is requested to telephone the undersigned at the telephone number listed 
below. 

If any fees are due in connection with this filing, the Commissioner is hereby authorized 
to charge payment of the fees associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Ref: NN-K715). 

Respectftlly Submitted 



Dated: November 28, 2007 





JohnX!- Gorecki 
Registration No. 38,471 

John C. Gorecki.. Esq. 
P.O. Box 553 
Carlisle, MA 01741 
Tel: (978) 371-3218 
Fax: (978) 371-3219 
iohn@gorecki.us 
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